src/db.rs (2)

396-436: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract a shared row-mapper for ServerDetection.

load_server_detections and get_server_detection both inline the same 6-field closure. The codebase already has a convention for this (row_to_account); doing the same here avoids column-order drift if the schema changes.

♻️ Suggested extraction

+    fn row_to_server_detection(row: &rusqlite::Row) -> rusqlite::Result<ServerDetection> {
+        Ok(ServerDetection {
+            host: row.get(0)?,
+            software_name: row.get(1)?,
+            software_version: row.get(2)?,
+            software_repository: row.get(3)?,
+            meta_json: row.get(4)?,
+            updated_at: row.get(5)?,
+        })
+    }
+
     pub fn load_server_detections(&self) -> Result<Vec<ServerDetection>, NoteDeckError> {
         let conn = self.lock_read()?;
         let mut stmt = conn.prepare_cached(
             "SELECT host, software_name, software_version, software_repository, meta_json, updated_at FROM server_detections",
         )?;
-        let rows = stmt.query_map([], |row| {
-            Ok(ServerDetection {
-                host: row.get(0)?,
-                software_name: row.get(1)?,
-                software_version: row.get(2)?,
-                software_repository: row.get(3)?,
-                meta_json: row.get(4)?,
-                updated_at: row.get(5)?,
-            })
-        })?;
+        let rows = stmt.query_map([], Self::row_to_server_detection)?;
         Ok(rows.collect::<rusqlite::Result<Vec<_>>>()?)
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/db.rs` around lines 396 - 436, Extract the duplicated six-field
`ServerDetection` row mapping into a shared helper, following the existing
`row_to_account` convention. Update both `load_server_detections` and
`get_server_detection` to pass that helper to `query_map`, preserving their
current result and optional-row behavior.

---

394-436: 🚀 Performance & Scalability | 🔵 Trivial

No eviction policy for server_detections.

Unlike notes_cache/chat_messages_cache, this table has no TTL/cap-based cleanup. Rows are small, so this is likely a non-issue today, but if ServerInfoService ends up being invoked for many transient remote hosts (link previews, federated timelines), consider adding it to cleanup_with_eviction-style maintenance later.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/db.rs` around lines 394 - 436, The current server_detections additions do
not include eviction maintenance. Extend the database cleanup flow, specifically
cleanup_with_eviction or its existing maintenance path, to apply an appropriate
TTL or capacity-based eviction policy to server_detections, while preserving the
existing load_server_detections and get_server_detection behavior.

src/server_info.rs (1)

56-56: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

inflight host-lock map grows without bound.

Entries inserted by host_lock (via .entry(host).or_default()) are never removed, unlike the self-cleaning revalidating set right beside it. Over a long-running process, every distinct host that ever hits a cache miss adds a permanent String + Arc<Mutex<()>> entry that's never freed — a slow, unbounded memory leak if the service ever sees many distinct hosts (e.g. via federated content across many instances, not just logged-in accounts).

♻️ Suggested cleanup after releasing the per-host guard

             CachePlan::Miss => {
                 let lock = self.host_lock(host).await;
-                let _guard = lock.lock().await;
-                // ロック待機中に先行リクエストが保存した行を拾う (dedup)
-                if let Some(det) = self.db.get_server_detection(host)? {
-                    if plan_for(Some(&det), now_ms(), SERVER_DETECTION_TTL_MS) == CachePlan::Fresh {
-                        return Ok(det);
-                    }
-                }
-                self.detect_and_store(host).await
+                let result = {
+                    let _guard = lock.lock().await;
+                    // ロック待機中に先行リクエストが保存した行を拾う (dedup)
+                    if let Some(det) = self.db.get_server_detection(host)? {
+                        if plan_for(Some(&det), now_ms(), SERVER_DETECTION_TTL_MS)
+                            == CachePlan::Fresh
+                        {
+                            Ok(det)
+                        } else {
+                            self.detect_and_store(host).await
+                        }
+                    } else {
+                        self.detect_and_store(host).await
+                    }
+                };
+                // No other waiter holds a clone of this lock — safe to drop the entry.
+                let mut map = self.inflight.lock().await;
+                if map.get(host).is_some_and(|l| Arc::strong_count(l) == 1) {
+                    map.remove(host);
+                }
+                result
             }

Also applies to: 72-95, 145-148

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/server_info.rs` at line 56, Update the inflight host-lock lifecycle in
host_lock so each host entry is removed from the map after its per-host mutex
guard is released, matching the self-cleaning behavior of revalidating. Ensure
cleanup only removes the entry associated with the completed lock and does not
race with a new waiter or lock acquisition for the same host. Keep serialization
intact while preventing stale host keys and Arc<Mutex<()>> values from
accumulating.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes